NAs I started to re-read my previous article, I started to re-think some of theNideas that were expressed in it. First, understanding how a routine works isNimportant. Second, "scrolling right" is not exactly correct. Third, aNsumming-up of "order" is probably in order, before going into the rest of the
subject.
NThe next phase would probably be the creation of the "map", which I guess isNthe term used to described the background of the game. As I mentioned in theNprevious article, I used the MEGA-MAC-MAP program created by Brian Bell, akaNMr. Amos, to create the background map. In my opinion, the creation of theIbackground map is in itself a subject that could involve much discussion.
NGetting back to the re-thinking of the previous article, I decided to reviewNsome points that were only briefly described. The map loading routine onlyNloads the map into memory BUT does not display it on the screen. There is a3routine that displays the first portion of the map.
NThe ingenious part of the map displayer routine is that only a portion of theNmap rather than the whole map is being displayed, thus the routine savesNmemory! As you probably have noticed, the wideth of the display was 336 ratherNthan 320. Why? If you take 336 and subtract 320, you get 16 which just happens%to be the wideth of one icon or tile.
NThe map displayer routine displays part of the map, but how do you scroll theNmap. You change the tiles that extend just beyond the visible display or!screen! Is that not a great idea?
NI remembered that "scrolling right" was not accurate. The map actually scrollsNto the left, which gives the illusion of movement to the right. This is an oldCHollywood technique or idea which was borrowed by game programmers.
NAnyway, the main purpose of the screen displayer routine is to set up theNinitial screen, before the actual scrolling routine begins. The scrollingNroutine begins in the "main loop" of the program, using a simple X=X+1Ncounter! Now remember that originally the sole purpose of the X=X+1 counter+was to scroll the map 1 pixtel to the left.
NNow how does the program know that the map has scrolled 16 pixels to the left,Nwhich is the wideth of one tile? By the cryptic If X MOD 16=0 decisionNstatement. MOD only recognises 16 numbers: 0 to 15. Thus, when the scrollingNbeginnings, it starts counting from 0 to 15. When X = 0 again, the main loop6is exited, and the map right routine is then executed.
NBasically the map right routine pastes the next set of tiles at the far rightNof the display. Once this is done, the program goes back to the main loop andNcontinues where it left off in the scrolling. As you probably know, the X=X+1Ncounter will count up and beyond the number 16, however this has no effect onNX MOD 16=0, as it will continue to count from 0 to 15 only. It is a rather
ingenius decision maker!
NI hope that you math wizards will be patient here, as I am sure that at leastNone person out there will find this kind of interesting as least in makingNdecisions in programming. I suppose this MOD decision maker could be used in
other programming problems.
NNow for filling the background map. Initially I created this IFF grid, so thatNI create tiles 16x16 pixels square. For me, the difficult part was coming upNwith ideas to fill in the background map. Here is an example from myNMartianette PD demo which shows the grid being filled in with objects for theNbackground scene. I created some of the objects, while others were borrowed
from Mr. Amos art disks.
NIf you are using objects from pictures which used different palettes of color,Nyou have to re-map the pictures to make the colors fit the current paletteNbeing used. DPaint offers a re-map option to do this. The way I did it was toNload in first the grid picture with the palette of colors which were currentlyNbeing used. I would then switch to another screen and load in the pictureNwhich contained the object I wished to use. Of course, the previous palette ofNcolors would be lost in the process, so I would use the option to "restore"Nthe previous palette. Now the picture, which contained the object I wanted,Nhad the same palette of colors that I had picked for the game, but the pictureNlooked all messed up, because the colors were all wrong. What to do? Well, INwould finally use the re-map option to re-map the colors, so the picture wouldNbe restored to it's approximate color scheme. Now I could cut out the object and paste onto the grid picture.
NAs far as I understand the re-map option, it basically takes the picture whichNcontains the object you desire and tries to match the colors from the sourceNpalette (pic containing object desired) to the destination palette (pic usingNpalette of colors for your background scene). Of course, the match is not*exactly the same but more correctly close.
NGetting back to the grid picture, I now cut up the picture into "tiles" whichNare then stored sequentially in a file or "bank". There is a simple utility?which can do this for you. Here is the coding for this utility:
For X=0 To SW-1) Get Icon IC,X*W,Y*H To(X+1)*W,(Y+1)*H
Inc IC
Next X
Next Y
Return
Screen Close 0
[36mNHere is where the fun starts. Run the "map" making program, then load in theN"tile" file. By pasting the tiles on the screen, you can create any type ofNbackground scene you desire. Once you have the background scene that you8desire, save it, and give it a name with .map extension.
NYou can now load in this map file in the map loading routine, which was givenNin the previous article. Run the program, and the background scene will scroll*from beginning to end over and over again!
NI suppose the weakness of the previous simple utility, the tile cutter, isNthat it can only cut up one screen's worth of tiles. If you need more tiles inNthe file, a different method can be used. Here is another utility, theNicon-file-to-picture program, which was written by Brett George, and which you+might find interesting. Here is the coding:
[36mNRem This program will convert your icon file to a picture. (I have included aNpicture which contains icons from a game, Forbidden Zone, on which I hadNworked earlier.) Each icon will have it's own border around it, so you can.easily "grab" the icon's back at a later date.
Screen Open 0,320,256,32,0.Paper 0 : Cls 0 : Curs Off : Ink 1 : Flash Off Centre "Icon's to iff converter"
Print : Cmove ,2GA$=Fsel$("*.Abk","","Please choose icon","bank to be converted to iff")4If A$="" Then Print "You must select a file!" : Edit
Load A$:If Length(2)=False Then Print "File does not exist" : Edit/Print "You have a total of";Length(2);" Icon's.*Input "Which icon should I draw first?";SS
If SS=0 Then SS=1
For Z=SS To Length(2)
XX=Deek(Icon Base(Z))*16
YY=Deek(Icon Base(Z)+2)! If YY>CY Then Add BY,YY : CY=YY* If X+XX>320 Then Add Y,CY+6 : X=0 : CY=0
Exit If Y+YY+3>256
Box X,Y To X+XX+1,Y+YY+1
Paste Icon X+1,Y+1,Z
Add X,XX+6 Wait 10
NextJSave Iff Fsel$("","Icon's.Iff","Please choose name to save","Iff picture."
Print Z-1;"/";5Print Str$(Length(2))-" ";" Icon's printed to screen"
Erase 1
[32mNBasically you can use a "grabber" program which will load in your pictureNwhich contains the icons within boxes. You can then grab the icons. You thenNload in another picture full of icons, and grab them also. This new set ofNicons will just be added on to the previous icons. You can continue doingNthis, until you have all the icons loaded in. Now save them to a tile file.NUsing this method, I grabbed up to 500 icon's, if I remember correctly. (Now6that I think back over this, I may have over done it.)
NIn conclusion, after I reviewed all the steps needed to create a backgroundNscene, I wondered why Europress in their infinite wisdom could not haveNdeveloped an integrated development system to do all of these things. ThisNall-in-one utility could have made life much simpler for people developingNsoftware. About the closest to this ideal was Brian Bell's REALITY! SoftwareNConstruction Kit. What may be your opinion on this? I wonder if an all-in-oneNutility for game or software construction would be worth developing in the
(.txt)